Database queried communications services, such as 800 and 900 services which require information look-up in order to route each call, have become increasingly critical for day-to-day operations of a large number of telephone subscribers. As the vital pipeline to a vast pool of callers, telephone calls made to subscribers of these services represent potential business opportunities and therefore need to be routed, completed and handled by telecommunications carriers and subscribers of these services represent potential business opportunities and therefore need to be routed, completed and handled by telecommunications carriers and subscribers alike, in the most efficient manner. To that end, communications carriers have enhanced these services by offering two major optional features, namely, 1) "advanced routing", which aims to enable subscribers to get optimal performance from their call handling resources and 2) "calling party identification" which purports to give subscribers some background information regarding the caller.
The advanced routing features are implemented as part of a plurality of inventions that have sprung out of the teachings of R. P. Weber in U.S. Pat. No. 4,191,860. Weber's patent described a technique for translating an 800 number to a Plain Old Telephone Service (POTS) number in a routing database using the dialed number and the Numbering Plan Area (NPA) of the caller as routing parameters. New advanced routing features introduced by communications carriers allow subscribers to select from a broader class of routing parameters. Selection of these parameters however, is still limited to a restricted set. For example, in U.S. Pat. No. 4,611,094, Asmuth et al. disclosed a method for routing calls based on additional information received from the caller through a call prompting device and other carrier defined routing parameters, such as time of day, day of the week, time zone at subscriber's locations or calling station, etc. While subscribers can periodically change the value of these carrier defined parameters or send congestion status information to the carrier's database via dedicated lines, as disclosed in U.S. Pat. No. 4,737,983, carriers, however, have been reluctant to allow external parameters other than congestion status information to influence routing decisions on a call by call basis, because of heightened security concerns raised by the interaction between subscriber's databases and carrier's routing databases. As a result, subscribers are forced to choose exclusively from carrier's defined parameters that may be ill-suited for their business needs. For example, a bank with its operations confined to one time zone would likely prefer to have routing decisions for calls originating from its depositors or debtors predicated on their account number or loan number, in addition to traditional routing parameters (such as time of day, day of week etc). However, meeting the requirements of this bank and each of a carrier's numerous subscribers wishing to customize routing decisions to their particular business environment will necessitate a prohibitively costly expansion of the carrier's routing database. In addition, carriers are legitimately concerned about the potential degradation in performance in terms of call setup time delay that could arise from the increase in size and attendant processing logic complexity of carrier's routing database. Thus, the current stat of the art prevents subscribers from defining their own routing parameters that could take advantage of the vast wealth of customer information stored in a subscriber's database to route calls in a manner that is more functional to their business needs and customers requirements.
In response to this need of the marketplace, other prior art systems have tried to overcome some of the limitations of the advanced routing features by forwarding all calls for a specific subscriber to a PBX at one of the subscribers' central locations. Under this approach, the PBX forwards the Automatic Number Identification (ANI) of the caller and the dialed number to an attached processor which retrieves from its database called a "subscriber's database", a destination number for the call. The formulation of this destination number can be predicated on factors such as dialed number, caller's ANI, call handling capacity at all locations as well as information in a customer record retrieved from the subscriber's database. The PBX then uses the destination number to redirect or transfer the call to the appropriate location using, for example, the call redirect pre-ringing feature or the call redirect post answer feature available in the AT&T Definity.RTM. PBX. This solution however, is rather expensive due to the cost associated with the advanced features of the PBX mentioned above. In addition, the PBX solution subjects the caller to post-dial delay inconveniences caused by the call transfer or call redirection mechanism.
Another arrangement which uses a PBX to redirect calls is described in U.S. Pat. No. 4,757,267 issued to B. Riskin on Jun. 17, 1987. The Riskin system uses a processor attached to a PBX to retrieve a destination number for the dealer of a national distributor or manufacturer that is closest to the caller. An alternative embodiment of the Riskin system discloses an arrangement wherein the processor, instead of being attached to the PBX, is linked directly to the carrier's routing database, thereby vitiating the need for the PBX as a call redirecting device. In this alternative embodiment, the carrier's database offloads its route selection functions to the processor which acts as a subscriber's database. Hence, the carrier's database participation in the route selection process is limited to relaying information back and forth between the carrier's originating switch and the subscriber's database. This approach may be arguably adequate for simple applications, such as the dealer locator type of services disclosed in the Riskin patent, wherein the caller entered digits or the NPA and the exchange number of the caller are matched to a destination number. For complex applications however, where multiple types of routing parameters play distinct but complementary roles in the formulation of a destination number for a call, the Riskin approach unduly penalizes the subscriber by forcing him or her to shoulder alone the entire development cost of a routing database and associated routing logic. In addition, Riskin's approach fails to exploit and use the processing and routing logic capabilities of the carrier's database.
The other feature introduced by carriers to help subscribers in their call handling tasks is broadly known as "caller identification" or "caller id" which purports to offer a competitive marketing tool by providing the subscriber with background information regarding the calling party. Automatic Number Identification (ANI), the most common form of caller id, when delivered to a subscriber's PBX, can be used as a key in a database search to retrieve additional information about the caller. This approach is adequate when all calls directed to a subscriber are routed to a single centralized location served by a PBX connected to a processor with a database containing all customer records. However, the caller identification features are less desirable for subscribers with a decentralized business structure or for subscribers who have implemented a distributed computing architecture characterized by each location having its own database storing information about local customers. For those subscribers, the use of ANI as a key in a database search to retrieve additional information about a caller constrains the subscriber to face some economically unattractive choices. One of these choices consists of duplicating the entire customer information database at all locations. Such a choice can become prohibitively expensive as the number of locations increases. In addition, coordination of database maintenance and updating for all locations can transform simple upkeeping tasks into an administrative nightmare. Another choice takes advantage of the advanced routing feature to route a call to a specific location based on the caller's ANI and the location of the database where the caller's records are stored. In that case, the database containing information about local customers is paired to another location's database storing the same information thereby allowing the call to be routed to the second location if the first location is unavailable. However, one of the deficiencies of this approach is that the carrier's database has to store not only callers ' ANI data but also additional data indicating the locations where records are stored for all callers associated with a subscriber.
Furthermore, the current architecture of database-queried communication services has prevented carriers to target specific market segments and to discretely differentiate various types of customers. Aiming to circumvent this limitation, some subscribers have assigned different 800 numbers to different classes of customers subject to different treatment. However, this solution is rather rigid and inflexible, since once a priority 800 number is assigned to a customer, he or she would still enjoy the same special treatment using that assigned number regardless of how little benefit may be derived by the subscriber out of that special treatment lavished on the caller.
In summary, the inability of the present architecture of database-queried communication services 1) to process calls based on existing routing parameters in the carrier's database and on functional parameters in the subscriber's database, 2) to allow subscribes to take advantage of the distributed computing trend in data processing and 3) to elevate these services to the additional role of a competitive edge tool for subscribers, is still an unresolved problem for subscribers of these services.